13/04/2025 - 19/04/2025

16/04/2025 19:01

Using this pattern finding playground I wrote in python, we can test different reco algorithms.

Here we're testing Sean's kmeans clustering vertex finding algorithm

\boldsymbol{\pi^+ \rightarrow e^+ + \nu_e}π+→e++νe\boldsymbol{\pi^+ \rightarrow e^+ + \nu_e}:
523840d65cf07d8eacf874047f1f83c9.png
224c5836d6b581d96bfe166331f926d5.png

\boldsymbol{\pi^+ \rightarrow \mu^+ + \nu_\mu \rightarrow e^+ + \nu_e}π+→μ++νμ→e++νe\boldsymbol{\pi^+ \rightarrow \mu^+ + \nu_\mu \rightarrow e^+ + \nu_e}
fdcc31ee1b00952f3bf1309f07768619.png
b527f26acda20713dfe460abd234fbd8.png

16/04/2025 19:05

Here's some performance metric information for the \boldsymbol{\pi^+ \rightarrow \mu^+ + \nu_\mu \rightarrow e^+ + \nu_e}π+→μ++νμ→e++νe\boldsymbol{\pi^+ \rightarrow \mu^+ + \nu_\mu \rightarrow e^+ + \nu_e} data set pattern finding:

530851090b7668edf504cd86adf32a95.png

Above conveys that sometimes the pattern count is correct (in this case it should always be 1 pattern), but we fail validation (validation here is just checking that every reconstructed pattern contains the same tracklets as the true patterns). This (in combination with the pattern reconsturction by particle composition plots above) shows evidence that sometimes we are missing tracklets from our patterns. My guess is somehow there are tracklets in the truth pattern that do not make hits in the ATAR, so they are not added to the reco pattern.

60d57879ae26b957a43d14a87a27ef60.png

The above conveys that when we have "complete" information in both the "front"/(x,z) ATAR planes and the "back"/(y,z) ATAR planes, then we rarely misconstruct the event. It's only when we have incomplete information in one of the planes that a problem happens. I should note here, that only the (x,z) ATAR planes are used to determine the reconstruction here; in other words, validation is only based on the (x,z) ATAR planes.

439a3d12edb7a5564925cea90b1cf6b4.png

This above plot was generated by constructing vertices from either just the (y,z) ATAR plane information or just the (x,z) ATAR plane information, and comparing how successfuly each of those approaches were. The above conveys that ~99% of the time, either the (x,z) or (y,z) planes contain enough information to correctly reconstruct that patterns. However, ~15% of the time one of the planes does not have enough information. In our "final" algorithm, we should definetly use the information from both planes in conjunction (this can be a little tricky).

ce5cb65b026c2dbcf20bfb961cc7664b.png

The above shows a small parameter scan using the parameters "sigma" and "n_iters" of Sean's vertex finding clustering algorithm. Sigma controls the "penalty" for points being distant from a centroid while n_iters is how many iterations of moving the centroids the algorithm goes through. We'd expect performance (average validation == percent of events that were valid) to increase with n_iters, but we don't see that. Also, we expect a "sigma sweet spot" smaller than 10 but we don't see that. I don't fully trust this plot was generated correctly; i.e. there may be some bug creating false information or otherwise.

16/04/2025 19:22

Sean did a bug fix where he prevented that clustering algorithm from adding vertices which no points are attached to. It didn't seem to change results:

9e70388ea35e1d94e4e38d9f8906f65e.png

16/04/2025 19:24

Here's what I was talking about when I said it's tricky to use both the (x,z) and (y,z) ATAR plane information, by simply throwing in (x,y,z) endpoints created from fitting both the (x,z) and (y,z) ATAR planes into the clustering algorithm, we get worse performance. My guess is we get the "worst of both worlds"; i.e. when either endpoint finding algorithm fails, the pattern reconstruction seems to fail. But the last plot seems to not support that hypothesis

52145ab7deb147bbfd8cf56a4024232f.png

defedcb213204324baf2a02c490e4889.png

1ac4d417fd3026605033a2a0372705a3.png

ee2666a15163d87b4c54c1d7813f5641.png

16/04/2025 20:39

Here are some more \boldsymbol{\pi^+ \rightarrow e^+ + \nu_e}π+→e++νe\boldsymbol{\pi^+ \rightarrow e^+ + \nu_e}: plots:

ed14da5ecf19a243a064ab1962e45242.png
368a5f24f3de8291c94d7e27019d147c.png
ef30a1eaf42461e4396028ea43b0a8ab.png
4292432b8fe419fde1c17868744b25ad.png

Reconstruction using 3D information (both planes) instead of either (x,z) or (y,z):
a477cdea2e97a0cdda6075ee25d37ed8.png
52c7048e1ae37033ac7ff6a82ad68e31.png
9897aea01ef8ab7cc82388b1865c0cef.png
4930b8101aac8e3bbfd94856165943b1.png

16/04/2025 20:48

I find a few things interesting:

  1. The \boldsymbol{\pi^+ \rightarrow e^+ + \nu_e}π+→e++νe\boldsymbol{\pi^+ \rightarrow e^+ + \nu_e} events don't seem to suffer as much perfromance drop from using 3D data as the \boldsymbol{\pi^+ \rightarrow \mu^+ + \nu_\mu \rightarrow e^+ + \nu_e}π+→μ++νμ→e++νe\boldsymbol{\pi^+ \rightarrow \mu^+ + \nu_\mu \rightarrow e^+ + \nu_e} events do.
  2. There is a much larger portion of \boldsymbol{\pi^+ \rightarrow e^+ + \nu_e}π+→e++νe\boldsymbol{\pi^+ \rightarrow e^+ + \nu_e} events where the (x,z) planes and (y,z) planes both fail to pass validation as compared to the \boldsymbol{\pi^+ \rightarrow \mu^+ + \nu_\mu \rightarrow e^+ + \nu_e}π+→μ++νμ→e++νe\boldsymbol{\pi^+ \rightarrow \mu^+ + \nu_\mu \rightarrow e^+ + \nu_e} events.
  3. There are much more \boldsymbol{\pi^+ \rightarrow e^+ + \nu_e}π+→e++νe\boldsymbol{\pi^+ \rightarrow e^+ + \nu_e} events that fail validation even when the (x,z) and (y,z) "match" (i.e. form the same vertices) as compared to the \boldsymbol{\pi^+ \rightarrow \mu^+ + \nu_\mu \rightarrow e^+ + \nu_e}π+→μ++νμ→e++νe\boldsymbol{\pi^+ \rightarrow \mu^+ + \nu_\mu \rightarrow e^+ + \nu_e} events.
  4. The (sigma,n_iters) parameter space seems to have the same trend for both the \boldsymbol{\pi^+ \rightarrow e^+ + \nu_e}π+→e++νe\boldsymbol{\pi^+ \rightarrow e^+ + \nu_e} and \boldsymbol{\pi^+ \rightarrow \mu^+ + \nu_\mu \rightarrow e^+ + \nu_e}π+→μ++νμ→e++νe\boldsymbol{\pi^+ \rightarrow \mu^+ + \nu_\mu \rightarrow e^+ + \nu_e} events